home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 4918 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.8 KB
  1. Path: prairie.nodak.edu!not-for-mail
  2. From: wstark@prairie.nodak.edu (Just Me)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Schildt <- Advanced Books
  5. Date: 11 Feb 1996 06:16:50 -0600
  6. Organization: North Dakota Higher Education Computing Network (NDHECN)
  7. Message-ID: <4fkmni$589@prairie.nodak.edu>
  8. References: <8BA8405.02C70020DE.uuout@sourcebbs.com>
  9. NNTP-Posting-Host: prairie.nodak.edu
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=US-ASCII
  12. Content-Transfer-Encoding: 7bit
  13.  
  14. In article <8BA8405.02C70020DE.uuout@sourcebbs.com>,
  15. DAVID MOHORN <david.mohorn@sourcebbs.com> wrote:
  16. >The only book that I know of that uses the notorious void main(void) is
  17. >his "Teach Yourself C" book.  But he only uses this for the first half
  18. >of the book.  This is only because he doesn't want the reader to be
  19. >overwhelmed with all the data types and other things until he has a
  20. >chance to explain how functions return values and pass arguments.
  21.  
  22. That is no excuse, which is harder?  To use 'int main()' consistantly
  23. thoughout a tutorial, and just say "trust me, I'll explain it all later", or
  24. to use 'void main()', and say "trust me, this works, so this is what I will
  25. use for now", and turn around and say "That is an incorrect way of defining
  26. 'main()' use this now."  Which is more confusing to those who actually don't
  27. know what they are doing yet?  I must be missing something, because I don't
  28. see why 'void main()' is any easier to "understand" than 'int main()',
  29. especially since you have to un-teach the 'void main()' later.  I wonder
  30. what ever happened to "get it right the first time" attitude.
  31.  
  32. >I haven't read the "Annotated Standard" book either.
  33.  
  34. Here is the entire annotation for section 5.1.2.2.1 Program startup:  Typos,
  35. and subscripts are mine.
  36.  
  37. 5.1.2.2.1 Program startup: Remember, the names 'argc' and 'argv' are
  38. arbitrary.  They could be any other legal identifiers you like.  (However,
  39. using 'argc' and 'argv' follows generally accepted practice.)
  40.  
  41.   In most implementations, the return value from 'main()', if there is one
  42. [1], is returned to the operating system.  Remember, if you don't explicitly
  43. return a value from 'main()' then the value passed to the operating system
  44. is, technically [2], undefined.  Though most compilers [3] will automatically
  45. return 0 when no other return value is specified [4] (even when 'main()' is
  46. declared as 'void' [5]), you should not rely on this fact [6] because it is
  47. not guaranteed by the standard [7].
  48.  
  49. The annotated ANSI C standard, pp 6-7
  50. Herbert Schildt
  51. (ISBN 0-07-881952-0)
  52.  
  53. [1] There is ALWAYS a return value from main(), or at least the C startup
  54.     code that calls main() thinks so.  Where the value is grabbed from is
  55.     anyone's guess, but if you put 'return 0;' at the end of 'main()', you
  56.     will know where the return value comes from.
  57.  
  58. [2] No technically about it, it IS undefined.  Though an undefined return
  59.     value is not as bad as undefined behavior (declairing 'main()' as void
  60.     later in the paragraph).  Hint on how to avoid this problem: always put
  61.     'return 0;' at the end of 'main()', unless you have a reason to put
  62.     something else there.
  63.  
  64. [3] How would the compiler know to return 0 at the end of 'main()' without
  65.     the programmer telling it so?  Hint: just put 'return 0;' at the end of
  66.     main, and be sure what is being passed back.
  67.  
  68. [4] How can you expect a randomly selected compiler to both (1) figure out
  69.     that you did not return a value in 'main()' and (2) actually return
  70.     something meaningful (0 in this case).  Solution:  put 'return 0;' at
  71.     the end of 'main()', and not worry about it.
  72.  
  73. [5] 'main()' may NOT be declared as 'void'.  The more likely reason that
  74.      the compiler appears to return 0, if no other value is returned is poor
  75.      Mr. Schildt got very unlucky with a couple of test programs (if he in
  76.      fact tested his theories, which is a dangerous practice to rely on), and
  77.      passed on the results as fact.
  78.  
  79. [6] What fact are we talking about there?  compilers automatically return 0,
  80.     even if you declare 'main()' as returning 'void', or forget to return a
  81.     value from 'main()'.  This is most definately not a fact, and a very
  82.     inappropriate statement, especially when the standard on the opposite
  83.     page doesn't support it.
  84.  
  85. [7] damned straight!  This is an annotation of the standard, so writing a
  86.     back-handed blessing of wrong practices is inappropriate.  This
  87.     paragraph is a good example of what not to do, but unfortunately, Mr.
  88.     Schildt failed to point that out.  Unless that is what he meant by the
  89.     last sentance.  In which case, he gave too much information about what to
  90.     expect for undefined behavior (implying that it is really not undefined
  91.     in most cases).
  92.  
  93. There are many more examples of wrong annotations, but reading them makes
  94. my head hurt.  There is rumored to be a overly complete list of errors in
  95. the annotations available on the net. (I don't know where it is, neither do
  96. I care).
  97.